Hace dos años, servir modelos de lenguaje en producción era un ejercicio de fragmentación. Cada equipo que llegaba al problema acababa eligiendo entre una docena de opciones (Hugging Face Text Generation Inference, DeepSpeed-MII, FasterTransformer, llama.cpp servers, implementaciones caseras sobre PyTorch), y la decisión rara vez era definitiva. Hoy, aunque alternativas serias persisten, vLLM se ha convertido en el motor por defecto para la mayoría de equipos que sirven modelos en GPU. Y el crecimiento no ha sido casual: es el resultado de un ritmo de mejora muy consistente durante dos años.
Este post repasa los cambios importantes en vLLM durante los últimos meses y los enmarca en lo que significan para quien opera el servicio. No es una lista de features, sino una lectura de qué problemas resuelven las mejoras y qué sigue quedando por resolver.
El momento de madurez
vLLM empezó como un proyecto académico centrado en una idea concreta (PagedAttention, la gestión eficiente de memoria KV durante la inferencia) y ha crecido hasta convertirse en una plataforma con un ciclo de releases predecible, una API estable y un ecosistema de usuarios empresariales. La consolidación se nota en detalles: la documentación es mejor que hace un año, los benchmarks que publica el proyecto son más sinceros, la integración con frameworks de orquestación (Ray, Kubernetes) es de primera clase.
Pero lo más relevante es técnico: la ventaja original de PagedAttention en throughput era notable pero no abismal. Hoy, vLLM en su versión actual tiene varias ventajas acumuladas sobre alternativas equivalentes que suman un factor de 2x o 3x en throughput para cargas típicas. Eso se traduce directamente en coste de infraestructura.
Prefix caching: lo que más ha cambiado
La mejora que más impacto ha tenido en el último año es el prefix caching automático. Cuando muchas peticiones comparten un prefijo (typical case: el system prompt de una aplicación, o el contexto común de un RAG), vLLM ahora detecta la coincidencia y reutiliza la cache de atención ya calculada. El efecto práctico es que cargas que antes ejecutaban la misma cabeza de prompt miles de veces al día ahora lo hacen una sola vez por nodo.
Para aplicaciones con mucho repetido (asistentes con instrucciones largas fijas, RAG con contexto recurrente, chat con historial compartido entre turnos), el ahorro en latencia y coste es muy real. En casos que he visto medidos, latencias que estaban en el rango de 500-800 ms han caído a 150-200 ms con el mismo hardware y modelo, simplemente activando prefix caching. Y el throughput agregado sube proporcionalmente.
La integración es además sin fricción: no hay que configurar nada, funciona automáticamente. Para un equipo que ya está usando vLLM, pasar a la versión con prefix caching es cuestión de actualizar.
Speculative decoding: la segunda gran mejora
La técnica consiste en usar un modelo pequeño rápido para predecir varios tokens por adelantado y luego verificar esas predicciones con el modelo principal. Si las predicciones son correctas, el modelo grande valida en una sola pasada lo que habría requerido varias, y la latencia efectiva baja.
vLLM ha incorporado speculative decoding con varias opciones de modelo borrador. La mejora en latencia es especialmente notable en modelos grandes (70B+) donde cada token individual cuesta mucho. Para cargas interactivas donde la experiencia de usuario depende del tiempo al primer token y la velocidad de generación, es un cambio cualitativo.
Lo único a tener en cuenta es que speculative decoding añade complejidad operativa: necesitas desplegar el modelo borrador junto al principal, y afinar el ratio de aceptación para tu carga específica. Para la mayoría de despliegues estándar, el ratio por defecto va bien, pero para casos atípicos merece la pena medir.
Multi-LoRA: un caso específico
Para equipos que sirven múltiples fine-tunes del mismo modelo base (típico en SaaS multi-tenant donde cada cliente tiene su adaptador), vLLM ha madurado el soporte multi-LoRA significativamente. Puedes cargar un modelo base y cientos de adaptadores LoRA, y la inferencia se enruta al adaptador correcto por petición sin recargar el modelo.
Esto transforma la economía de servicios multi-tenant con LLM. En vez de desplegar un modelo por cliente (que no escala), desplegas un modelo base compartido y un adaptador por cliente. Los adaptadores son pequeños (pocos MB), así que puedes tener cientos activos en memoria de GPU simultáneamente.
La aplicación típica de esto en 2025 es SaaS B2B con IA personalizada: cada cliente entrena su propio adaptador sobre sus datos, y el servicio sirve a todos con un solo modelo base. vLLM es la pieza que hace esto operativamente viable.
Comparación con alternativas
Las alternativas serias siguen siendo Text Generation Inference de Hugging Face y TensorRT-LLM de NVIDIA.
TGI ha mejorado mucho durante el último año y ahora tiene features comparables a vLLM en la mayoría de áreas. Es una buena opción si ya estás integrado en el ecosistema de Hugging Face y valoras la consistencia con sus otras herramientas. En throughput puro, los benchmarks independientes siguen dando ligera ventaja a vLLM, pero la diferencia es menor que hace un año.
TensorRT-LLM ofrece el throughput más alto en hardware NVIDIA cuando puedes dedicar tiempo a la optimización específica. El precio es un pipeline de compilación más complejo y menos flexibilidad para cargas dinámicas. Para servicios de alto volumen con cargas predecibles, merece la pena considerarlo; para servicios con cargas variables o que cambian modelos con frecuencia, vLLM es más cómodo.
Hay una tercera línea, más ligera, representada por llama.cpp y derivados como Ollama. No compiten con vLLM en throughput sino en simplicidad y flexibilidad. Para prototipos, aplicaciones locales y despliegues pequeños, siguen siendo excelentes. Para servicios que atienden decenas o cientos de peticiones concurrentes, vLLM es superior por diseño.
Lo que sigue siendo punto débil
vLLM no es perfecto y conviene tener claros sus límites.
El soporte multi-GPU ha mejorado pero sigue siendo más frágil que el single-GPU. Las configuraciones con tensor parallelism a través de varias GPUs están bien documentadas, pero en la práctica pueden surgir problemas con ciertos modelos grandes que requieren tuning específico.
El soporte de hardware no-NVIDIA va por detrás. vLLM funciona en AMD con ROCm y se ha portado a Intel Habana, pero la experiencia en esos chips es claramente inferior a la NVIDIA. Para quien está en hardware alternativo, el ecosistema todavía no está maduro.
Y el consumo de memoria durante el arranque es alto. vLLM carga el modelo y los buffers de KV cache agresivamente, y para modelos grandes en GPUs con VRAM limitada, puede ser difícil hacer que quepa. Hay opciones de configuración para esto, pero exigen entender bastante bien el modelo.
Lo que significa para quien opera
Mi conclusión después de un año operando servicios con vLLM en producción es concreta. Para prácticamente cualquier equipo que esté sirviendo LLMs en GPU NVIDIA con cargas no triviales, vLLM es la opción con mejor retorno en inversión de tiempo. Las mejoras recientes (prefix caching, speculative decoding, multi-LoRA) han ampliado la ventaja sobre alternativas en los últimos seis meses.
Lo que recomendaría a un equipo empezando hoy: arranca con la última versión estable, mide con tu carga real antes de micro-optimizar, activa prefix caching desde el principio si tus prompts tienen partes repetidas, y considera speculative decoding solo si las mediciones te muestran que la latencia es un problema real. No intentes optimizar todos los knobs a la vez; vLLM funciona bien con configuración por defecto para la mayoría de casos.
A medio plazo, lo que espero es que vLLM mantenga su ritmo de mejora y se convierta en una infraestructura dada por sentada, como hoy son Redis o PostgreSQL en su respectivo nicho. Para quien está construyendo productos sobre LLMs, esa estabilidad es una buena noticia: menos tiempo en infraestructura, más en el producto.
